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programming language built upon rule-based pattern matching. 
Emphasis is placed cn simplicity and flexibility in the 
design. The feasibility of the proposed grammar (Omega-1.5) 
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assessment of the overall Omega system. 
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I. IHTBODOCTION 



A. BaCKGBOOND 

The evolving complexity of modern computer applications 
is leading to basic changes in the nature of programming. 
There is a growing awareness that conventional programming 
languages are not adequate for building computer systems. 
Programmers are demanding increasingly sophisticated tools 
for understanding and manipulating intricate, ill-defined 
problem domains. Successive conventional languages have had 
little success in providing additional tools to help the 
programmer combat the complexity barriers. Although the 
languages are getting larger, they are not getting stronger. 
As John Backus stated, "Inherent defects at the most tasic 
level cause them to be fat and weak...." [Bef. 1: p. 613] 

Backus further stated that a major limitation of the 
conventional languages was the " word-a t-a-time" programming 
style. An example of this style is evidenced in the array 
construct [Bef. 2: p. 404]. Arrays are processed by 
performing an action on each individual element, with all of 
the indexing and loop control that this action requires. 
Thus, the programmer is occupied with minute implementation 
details rather than confining his thinking to the larger 
conceptual units of the task. 

Programmers must shift their focus away from the 
detailed specifications of algorithms. The basic use of 
programming systems is not in developing sequences of 
instructions for accomplishing tasks, but in expressing and 
controlling descriptions of computational processes [Bef. 3: 
p.393]. High level languages were initially developed to 
free the programmer from the burdensome details of machine 



8 



code. Languages with even higher levels of abstractions are 
now reguired to rescue the programmer . from inundation by 
unnecessary implementation-related details. Increased 
semantic power from the use of abstraction cannot be 
achieved, however, at the expense of architectural effec- 
tiveness. The conventional notion of programming languages 
needs to be reevaluated. 

alternatives to conventional languages have existed for 
quite some time. An early example is LISP. The original 
LISP system was characterized by the application of pure 
functions to list structures. This application of a func- 
tion tc its argument is indicative of applicative program- 
ming. Other alternatives tc conventional languages are 
object-oriented programming and logic programming. One 
language framework that combines the features of the appli- 
cative, object-oriented, and logic programming categories is 
a language called Omega [Sef. 4]. This thesis shall focus 
on the features of the Omega framework. 

B. THE C3EGA LANGUAGE 

In order to understand the foundations of Omega, it is 
necessary to analyze the three categories of alternative 
languages mentioned ir section A (see sections C, D, and E) . 
The influences upon Omega from languages in these categories 
will become guite obvious as the features of Omega are 
explored. First, however, a general overview of Omega is in 
order. The backbone of Omega is the concept of object- 
oriented programming. A pioneer language in the object- 
oriented field was Simula [Ref. 5]. As the name suggests, 
Simula views all programming as simulation. This concept is 
fundamental to Omega's view of objects. 

One unique feature of Omega is the provision for four 
alternative syntactic forms which represent the same 
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language. The first form (Omega-1) uses a predicate logic 
style and is the easiest to parse. The second and third 
forms use syntactic "tricks" to approach a pseudo-natural 
language format. This style is much easier for a naive 
computer user to read. Omega-4 further addresses the read- 
ability issue by using a two-dimensional format built upon 
the use of a form. The notion of multiple syntaxes creates 
a rich environment that supports many levels cf user 
sophistication. 

C. OBJECT-ORIENTED LANGUAGES 

The object-oriented paradigm of Simula was smoothed and 
cemented in the Smalltalk language [Ref. 6]. It was the 
Smalltalk programming system that actually produced the term 
"object-oriented.” Although there is some evidence of LISP 
in Smalltalk, the class notion from Simula has become domi- 
nant in the design. The class notion is the basic struc- 
tural unit, with instances of classes, or objects, being the 
concrete units which comprise the Smalltalk system. 

There are many advantages in the object-oriented 
approach. The simulation paradigm of objects is well suited 
to modeling real-world objects. Another advantage is the 
concept cf state — objects hold the state of a computation. 
Additionally, an object orientation easily supports such 
concepts as abstract data types, information hiding, and 
modularization. A more intuitive appeal of objects is 
simply a sense of uniformity. No object is given any 
special status; there are no "second class citizens." A 
user-defined object is an object just like a system-defined 
ob j set. 
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D. APPLICATIVE LANGUAGES 



Applicative programming extends the model of mathematics 
to the world of computer programming. Applicative languages 
basically involve the application of functions to their 
arguments. Underneath the various syntactic idiosyncrasies 
of applicative languages is the rigorous structure of the 
lambda calculus. Various syntactical forms are merely 
"syntactic sugar" [Ref. 7] to help soften the rigid appear- 
ance cf the lambda calculus format. Two well known applica- 
tive languages are pure LISP [Ref. 8] and the FP language 
[Ref. 1]. 

Applicative programming encourages the use of higher 
levels cf abstraction through the use of functionals. 
Functicnals are mechanisms for modifying the behavior of 
existing programs by combining primitive computational units 
into complex, powerful collections. Specifically, a func- 
tional is a function which receives functions as arguments 
and returns functions as results. 

Another advantage of applicative programming is the 
notion of manifest interfaces. That is, the input-output 
connections to a subexpression are distinct and there are no 
hidden interfaces to complicate the semantics of a process. 
A final benefit is parallel evaluation, which is supported 
by the evaluation crder independence of expressions. 

Applicative language programming is essentially synony- 
mous with value-oriented programming. Consegue nt ly , it is 
subject to the basic characteristics that are associated 
with values. The notions of time and state are lacking in 
value-criented programming. This limits applications where 
temporal relationships are required. 



E. ICGIC PROGRAMMING AND INFERENCE SYSTEMS 



The development cf Prolog [Ref. 9] in 1970 has made 
logic programming quite popular in recent years. Prolog has 
many applications in the artificial intelligence and infer- 
ential programming fields. It has been selected by the 
Japanese as the core language for their much-touted Fifth 
Generation Project [Ref. 10]. Prolog uses rule-tased 
pattern matching as the basis for computation. A Prolog 
program consists of clauses, where each clause is either a 
fact or a rule about how the solution may be "inferred" from 
the database of facts. This is the first step toward logic 
programming. In conventional languages, different formal- 
isms are used for expressing programs, databases, specifica- 
tions, and constraints. Logic can be used to provide a 
single uniform language for all of these tasks. 

Inference systems are usually associated with artificial 
intelligence applications. Rule-based paradigms have been 
used for problem-solving production systems and even for 
knowledge representation. A popular application has been in 
expert systems. For example, MYCIN [Ref. 11] and INTERNIST 
[Ref. 12] are two well-known systems in the medical field. 
XCON [Ref. 13], another example, is a system used at 
Carnegie-Mellon University for configuring computer 
components. 

F. DEVELOPING AN ALTERNATIVE SYNTAX 

The objective of this thesis is to develop and implement 
a natural language style syntax for the Omega language. 
Concepts from the Omega-2 and Omega-3 syntaxes will be 
synthesized into the development of an Omega- 1.5 grammar. 
The ideal engineering solution for Omega- 1.5 is to create a 
highly readable syntax at a minimal cost. Flexibility, as 
well as simplicity, is key to the design. 
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The feasibility cf the 1.5 grammar was demonstrated by 
constructing a translator to translate programs written- in 
the 1.5 grammar into the predicate logic syntax of Omega-1. 
The development of the translator was considered to be a 
learning process in that language features of the 1.5 
grammar were studied and changed as necessary throughout the 
programming process. Translator features such as efficient 
code generation and elaborate error checking were considered 
to be of secondary importance. 

Another objective of the thesis was to develop example 
applications in the 1.5 grammar and to run them first on the 
translator and then to run the translation on the McArthur 
interpreter [Hef. 14]. This approach permits an informal 
evaluation of the naturalized syntax. Additionally, it 
provides a beneficial vehicle for evaluating potential 
application areas for the Omega-1.5 grammar. 

The Omega language is still in the experimental stages. 
Therefore, some attention has been placed on the general 
features of the language. Possible future design modifica- 
tions are suggested and subjectively evaluated. Deviations 
from language features of the McArthur prototype are also 
noted. A final task is an introspective evaluation of Omega 
as a general-purpose programming language. 



13 



II. TEE OH EG A- 1 IMPLEMENTATION 



A. PEEP ACE 

General features of the Omega-1 syntax will be discussed 
in this chapter. The Omega concept was originally developed 
by Bruce MacLennan. A description of the language and a 
formal syntax for these constructs is presented in [Eef. 4]. 

These constructs were implemented by McArthur [Eef. 14] 

through a prototype interpreter. Some semantic and 

syntactic differences do exist between the original theory 
of the language and the actual implementation. A listing of 
these differences can be found in [Eef. 15]. The following 
summary will discuss Omega as amended by the prototype 
implementation. 

B. OEJECTS AND VALDES 

The basic elements in Omega are values and objects. A 
detailed discussion of the two is in [Eef. 16]. Briefly, 

objects are entities that have a unique identity and possess 
the following characteristics: 

• objects exist in time and can change in time. 

• objects may be created and destroyed. 

• objects are unique, but may be shared. 

• objects have a state (the sum of the relationships with 
all other objects in the system). 

Values are mathematical entities and thus have the following 
characteristics : 
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• values exist independently of time. 

• values are not subject to change. 

• values cannot be created or destroyed. 

Typical values in Omega include character strings, integers, 
and lists. a list is a collection of expressions enclosed 
by brackets. Two examples of lists are: 

[ red, white, blue ] 

[ 1 , 2 , [ 1 , 2 ]] 

C. RELATIONS 

Gelations are the "glue” which connect the components in 
Omega. In mathematical terms, R is a relation cn the n 
sets, s 1 ,s 2 ,.».s n , if R is a subset of the cartesian product 

I Sj I ... S . Informally, a relation is a set of 

tuples, which are simply ordered collections of objects and 
values. Onlike relational database models, named attributes 
are not used to describe tuples. Instead, elements of 
tuples can be described by value, by relative position, and 
by pattern-matching. Tuples in a relation are unique. 

Additionally, there is no order among the tuples in a 

relation. 

Relations are described either through pattern-matching 
or by name. A possible relation in Omega is: 

perform (compilers,[ scanning, parsing, 

code_gener ation ]) 

This relation is named by the identifier perform. It 
consists of a binary tuple, <compiler,[ scanning, parsing, 
code_generation ]>, that contains the object compiler and a 
list of the objects scanning, parsing, and code_generation. 
It should be noted that relations (and objects) in Omega 
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must te defined prior to their use. Definitions are estab- 
lished through procedure calls (section F) . 

Relations help determine the state of an object. An 
objects's state is defined by its associations with ether 
values and objects in each of the relations in which it is a 
member. Relations are also objects, although they differ in 
that they have the inherent value of their tuples. As 
objects, relations may participate in other relations as a 
member of a tuple. 

D. TEE PRODUCTION RU1E SYSTEM 

The behavior of the entities in Omega is described 
through pattern- directed production rules. Through these 
rules, state transitions in the system can be described. 
Rules are written as implications of the form: 

if <premise> -> <conclusicn> 

The premise consists of one or more boolean conditions 
pertaining to the state of the system. The conclusion 
defines actions to be taken whenever the conditions of the 
premise are true. 

Inquiries and constraints are two of the basic 
constructs in the premise condition. Inquiries are 
expressed as: 

if P(x,y,z) -> ... 

Here we are testing to see if there exists (existential 
quantification) a tuple <x # y,z> in relation P. The meaning 
of the premise depends upon the bindings of x, y, and z. If 
we assume that these are unbound variables, then P(x,y,z) 
will match any ternary tuple in relation P. The match will 
result in the binding of the tuple's components to the vari- 
ables x, y, and z. 
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A more complex inquiry might be: 
if P(x,y,z), Q(f,y,g) -> ... 

The comma between the two conditions denotes the logical 
conjunction of the two conditions in the inquiry. Thus in 
order for the premise to be true, the relations P and Q must 
each have a triple such that the second component of each 
triple is the same. When this condition occurs, the rule is 
said to ’’fire." 

The absence of a condition can also be tested. This has 
the form: 

-•P (x, y , z) -> ... 

Here the premise would be true if there were no ternary 
tuples in relation P. The interpretation of the absence of 
a tuple as the negation of its presence is dependent upon 
the assumptions of the programmer. Absence and negation are 
not necessarily synonymous. 

At this point, the binding of free variables should be 
discussed. Bindings of free variables remain in effect only 
for the duration of the rule. In other words, the scope of 
a free variable within a rule is confined to that rule. 
Free variables are net bound in a test for absence. Thus, 
the variables in the implication -«P(x,y,z) -> ... remain 

unbound. 

Constraints may also be used in a premise. Our example 
could be written: 

if P(x,y,z), x < 8 — > ... 

where x < 8 is a constraint. Constraints may be any boolean 
expression. 

The second part of the rule is the conclusion. 
Conclusion segments of an implication may be used to alter 
the state of the system. Consider the following: 
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if F(x,y,z) -> R(x,y) 



If through pattern- matching , the rule fires (the premise 
becomes true), an assertion, B(x,y), is established where 
the tuple <x # y> is added to the relation B. Remember the 
bindings of x and y in relation R will be the same as the 
bindings of x and y in relation P. 

The use of deletion in the conclusion segment is shown 

as: 

if P(x,y,z) -> R (x, y) , ->P(x,y,z) 

This will result in the removal of the tuple (that became 
bound to x, y, and z) from relation P. This is quite common 
in Omega rules. If one or more conditions in the premise 
are not removed in the conclusion, the conditions that 
precipitated the firing of the rule would remain in effect. 
Thus, the rule would keep on firing. An abbreviated syntax 
can be used to denote the cancel operation: 

if *P (x,y ,z) -> R (x, y) 

where *P(x,y,z) represents P(x,y,z) in the premise and 
-*P(x,y,z) in the conclusion. 

One other syntactical extension is the use cf else 
before an implication to establish a compound rule. Suppose 
we had the following: 

if *F(x,y), *Q(m,n) -> R(m). 
if *P (x,y) -> R (x) . 

In this example, we want the second rule to fire cnly when 
the first one fails. The first rule may never fire, 
however, since the matching of the tuple <x,y> in the P 
relation will fire the second rule. In this case, the 
example could be written as: 

if *P (x,y) , *Q (m ,n) -> R (m) 
else if *P(x,y) -> R (x) . 
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The implication associated with the else statement will only 
he evaluated if the first implication fails. 

A summary of the rule features is presented through the 
following example: 

if *P(x,y) ,Q(m,4),-R(s) ,x > 4 -> -Q (m,4) ,T (x) 
else if *P(x,y) -> T (y) - 

It shculd be noted that although many rules may have their 
premises satisfied (the rules are "trigger ed") , cnly one 
rule is executed (fired) at a time. The indivisibility of 
rules can be used to support mutual exclusion of processes. 

E. FUNCTIONS AND OTHER APPLICATIVE FEATDRES 

Named functions may be used to calculate components in a 
tuple. A function invocation is used in the conclusion of 
the following rule: 

if *P(x,y,z) -> Q(rest[x]). 

The argument to relation Q is a function (note the use of 
brackets for function calls) which returns a pointer to the 
tail of a list. In this example, variable x must be bound 

to a list in the premise condition of the rule. Function 

invocations may also be used as constraints in a premise: 

if *P(x,y,z), first[x] < 10 -> ... 

In this case, variable x must be bound to a list which has a 
first element less than ten. 

New functions are declared as follows: 

fn number_items [list]: if list = Nil -> 0 

else 1 + nuraber_items[ rest[ list ] ] . 
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The body of a function is a conditional expression similar 
in form to a rule. There are two qualifications. The 
premise can only be a boolean expression, while the conclu- 
sion can only be another expression. This ensures the 
absence of side effects. Note that the conclusion contains 
a recursive call. There are no iterative constructs in 
Omega. 

Functional bodies clearly display six desirable charac- 
teristics that can be obtained through the use of expres- 
sions. These characteristics include "transparency of 
meaning and purpose, independence of parts, recursive appli- 
cation, narrow interfaces, and manifestness of structure 
[Eef . 17:: p. 16]." 

Applicative expressions can also be used to calculate 
the value of an argument in a tuple. Consider the 
following : 

if *P (x,y , z) , y + 2 > 10, z - 1 < 5 -> 

Q (x,5 + z) . 

In this example, infix operators are used to calculate two 
constraints in the premise. One infix operator is also used 
to calculate an argument in the assertion of the tuple 
<x,5+z> for relation Q. All variables must be bound prior 
to participating in an applicative expression. 

F. PBOCEDORES 

Procedure calls are quite similar to the function invo- 
cations discussed in the previous section. Both processes 
return results which may be used in expressions. The under- 
lying mechanism of a procedure call is quite different, 
however, from that of a function. One important difference 
is that side effects are possible in procedure calls. This 
is a result of the use of rules to implement the actions of 
a call. 
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A procedure call involves synchronous communication; 
that is, the sender (object or process) that made the asser- 
tion expects a reply before continuing. The sender is 
usually expecting one or more rules to be processed prior to 
receiving a response. Procedure calls are distinguished 
from conventional relations by enclosing the asserted tuple 
in braces. This is illustrated in the following example: 

if *input (x) , state (g) -> push {x, mystack} . 

The relation push is a procedure call. It will be trans- 
lated by the system into the assertion push (a, x, mystack) . 
The object a is a system-supported relation that represents 
the sender. The relation a will be used as a mailbox to 
hold the response from an active rule that contains the push 
relation. This rule could be written as: 

if *push (a , x,stack) , *contents (list , stack) -> 

a (stack) , 

contents (cons[x, list], stack) ; 

By convention, a is placed as the leftmost member of the 
tuple <a,x,stack>. With the assertion of a (stack) , the 

sender may obtain the result and continue with the computa- 
tion. The tuple <a,x,stack> could be compared to the estab- 
lishment of a conventional activation record, while the 
mailbox a is analogous to the activation record of the 
caller. 

The above example shows that the result of a procedure 
call does not have tc be used in an expression. In this 
case, the returned value is used only for synchronization . 
Another procedure call which does not use the return value 
is the system-defined display procedure. This procedure 
sends a message to the screen. An example of a call that 
uses the return value would be: 

if *P (x, y , stack) -> 
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Contents (cons[ pop {stack} , x ], y) . 



In this case, the result from popping the stack will be 
appended to a list that is bound to variable x. 

G. SEQUENTIAL C0NTRC1 

Consider the following rule from a solution to the 
Towers of Hanoi problem: 

if *move (user, 1 ,source_peg, destination_peg, 

auxi liarv_peg) 

-> 

display {"Move disk 1 from peg "} , 
display {source_peg} , 
display {" to peg "} , 
displayn {destination_peg} , 
user (Nil) ; 

Naturally the programmer would like the message to print in 
order. This will not necessarily occur, however, with the 
current structure of the rule. No order is assumed for 
evaluating the conditions of the premise, and no order is 
assumed for executing statements in the conclusion. 
Further, there is no order associated with the evaluation of 
multiple production rules. 

A mechanism is therefore needed to give the programmer 
control over processes which transition through multiple 
states. The solution is a pair of braces. An open brace 
depicts the beginning of a seguential block, and a closed 
brace terminates the seguential block. The previous rules 
could be rewritten as: 



if *move (user, 1 ,source_peg, destination_peg, 

auxiliary_peg 



-> 



{ 
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display {"Hove disk 1 from peg '»} ; 
display {source_peg} ; 
display {'• to peg ”} ; 
displayn {destination_peg} ; 
user (Nil) 

}• 

Variables bound in the premise will keep their bindings 
throughout the sequential block. Bindings will also be 
retained in nested blocks. 

H. DIBECTOBIES 

It has been previously mentioned that relations and 
objects must be defined prior to their use. These defini- 
tion statements are used to bind a global name to the 
desired object or relation. Global names are controlled 
through directories. 

The original schema for Omega [Eef. 4: pp. 34-35] 
discussed the use of one public and a number of private 
directories. An obvious use for these directories is to 

enforce information hiding. A private directory can be used 
for access control as follows: 

Define {Private /'Push” , Newrel {} } . 

The define procedure call makes an entry into a directory 
partition. The Newrel procedure call returns a new relation 
object which is a unigue identifier. The name push is bound 
to the new relation object in the private directory. 

The creation of a new relation associates full access 
rights (capabilities) with the relation name. The access 
rights are read, add, and delete. It is possible to 
restrict access rights: 

Define {Public , "Push" , A ddCnly {Push} } . 



23 



The AddOnly call creates a copy of the system identifier 
that has been bound to the private name Push. The copy 
differs in that its rights have been restricted. The new 
identifier is then placed in the public directory where it 
can be generally accessed in accordance with its restricted 
access rights. 

Public and private directories were not defined in the 
McArthur prototype. A single directory named root was 
implemented as shown in the following definition. 

Define {root, "Push" ,nevrel {} } . 

I. PRODUCT ION ROLE SYSTEM 

The previous production rules are examples of active 
rules in the Omega system. These rules are normally entered 
into a file using a standard text editor (they can also be 
entered interactively). Active production rules constantly 
monitor the relations in their premises on a test-fire 
basis. A rule denotation ( « » ) is used to syntactically 
distinguish the production rules from command rules (section 
J) . A possible rule definition is: 

Define {root, " SampleRules, 

<< 

if *top_i tern (a, stack) , contents (list, stack) 

-> a (first[ list ]) 

»} . 

The rules have been entered in a passive status, basically 
parsed but not evaluated. To make the rules active, the 

procedure Act is used: 

Act {SampleRules}. 

The rules are then elevated to an active test-fire status. 
It is possible under the original Omega design to activate 
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and deactivate rules throughout a program. Rule deactiva- 
tion was not implemented, however, in the McArthur 
interpreter. 

J. INTERACTING WITH CHEGA 

A second category of rules is the command rules. These 
rules are used to interact with the system. Unlike produc- 
tion rules {which when activated are constantly evaluated) , 
the command rules are only evaluated once. The evaluation 
sequence for command rules is test, fire, and forget 
[Ref. 14: p. 30]. 

One useful application of command rules is queries. An 
example of a session with Omega that combines the command 
rules with the production rules is presented below: 

Define [root , "Married" , newrel {} } . 

Define {root, "Brother" , newrel {} } . 

Define {root , "Bill", newrel {}} . 

Define {root, "Karen" ,newobj {}} . 

Define {root, "Joe", newobj {}} . 

Define {root, "Jane", newobj {}} . 

Define {root, "Sample rules", 

<< 

if ^Brother (x, Joe) -> Married (x, Karen) ; 
if ^Brother (x, Bill) -> Married (x, Jane) ; 

»} • 

Act {Samplerules} . 

The definitions and production rules could have bean entered 
interactively or from a file. If a file is used, the file 
must be activated with the procedure Do. 

Suppose the user wanted to establish that Bill was the 
brother of Joe. He would enter Brother (Bill, Joe) . The 
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first production rule would fire thus asserting that Eill is 
married to Karen ( Harried (Bill, Karen) ). Next the user 

might enter: 

if Married (Bill, .Karen) -> Display ("Yes”} . 

Since Married (Bill, Karen) has been asserted. Omega will 

respond with Yes. 
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III. C BEGA-1 . 5: DESIGN ISSOES 



a. Gcais 

Four different syntactical forms have been suggested for 
the Omega language [Ref. 15]. The second and third alterna- 
tive forms suggest a pseudo-natural style that provides a 
greater degree of readability for novice (and experienced) 
users of the language. Readability has long been an issue 
in the development of computer languages. A 1973 memorandum 
by C. Hoare listed readability as one of the top five objec- 
tive criteria for good language design [Bef. 17: p. 6]. Ihe 
goal of the Omega-1.5 grammar was to develop an independent 
design that fulfilled the intent of the Omega-2 and Omega-3 
grammars (primarily Omega-2) and to test the feasibility of 
implementing such a design. Inherent in this objective were 
the following design characteristics: 

• Readability. The 1.5 grammar had to offer a notable 
increase in readability over the predicate logic style 
notation of Omega- 1. 

• Simplicity. 

1. The engineering solution must be simple and 
practical. 

2. The syntax should have a close correlation tc the 
Omega-1 syntax. The original thought was to have 
an injective mapping (after the removal of the 
noise words) from Omega-1.5 to Omega-1 (a function 
f:A->B is injective if aOa' implies f (a) Of (a ') ) . 

3. There should also be a close correlation between a 
translated version cf Omega-1.5 program and a 
program written in Omega-1. 
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4. Additional definition statements should be kept to 
a minimum. 

• Flexibility. A programmer should have the capacity to 
write a relation in many ways, • depending upon the 
context. The design should also be extensible. A 
programmer should be able to augment the given collec- 
tion of noise words as necessary. 

Upon completion of the design, a translator was built to 
test the design’s feasibility. Sample programs were then 
written to evaluate the completed design against the initial 
design goals. 

B. REPRESENTING OBJECTS AND VARIABLES 

Let us review the last example written in Omega-1; 

Define {root, "Married" , newrel {} } . 

Define {root, "Brother" , newrel {} } . 

Define {root, "Bill" , newobj {}} . 

Define {root, "Karen" , newobj {} } . 

Define {root, "Joe", newobj {}} . 

Define {root, "Jane" , newobj {}} . 

Define {root, "SanpleRules", 

« 

if *Brother (x , Joe) -> Married (x, Karen) ; 
if *Brother (x ,Eill) -> Married (x, Ja ne) ; 

»} . 

Act {SampleRules} . 

Bill, Karen, Joe, Jane have been defined as objects in this 
short program. The variable x represents an unbound vari- 
able. The following code is the same program written in 
Cmega-1 . 5 : 
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"Married" (procedure) is defined as a relation. 
"Brother” (procedure) is defined as. a relation. 

"Bill" (procedure) is defined as an object. 

"Karen” (procedure) is defined as an object. 

"Joe” (procedure) is defined as an object. 

"Jane” (procedure) is defined as an object. 

"Sample_rules" (procedure) are defined as 
Rules 

If given a person is the brother of Joe 
then the person is married to Karen; 

If given a person is the brother of Bill 
the the person is married to Jane; 
end_rules. 

The sample_ rules (procedure) are activated. 

Objects and variables may be written in the 1.5 grammar 

as: 



word_phrase = ncise_preps? noise_word? word 

The guestion mark means optional. A word is simply an iden- 
tifier, as classified by a scanner. The noise word category 
includes the indefinite articles a and an and also the defi- 
nite article the. Noise_preps is an extensible category 
(chapter IV) that represents prepositions. Noise_preps is 
defined : 

noise_preps = ncise_prep 

| noise_prep noise_preps 

The symbol " | " means or. A noise_prep is simply a preposi- 
tion. Notice the optional recursive call in the definition 
of noise_preps. This permits the use of multiple word prep- 
ositions. Examples of common prepositions are: 

to 

with 
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for 

in addition to 
according to 

Legal instances of the word_phrase category in Omega-1.5 
include: 



person 
the person 
with the person 
with George 
to George 

according to George 
according to the person 

Variables and objects can therefore be used as subjects, as 
direct objects, and as indirect objects. With the removal 
of the prepositions and articles, we have a bijective 
mapping for objects and variables in the Omega-1.5 and 
Omega-1 grammars. Thus, the translation of objects and 
variables is guite simple. 

C. EE1ATICNS 
1 . N ames 

In Omega-1, a relation is named by an identifier 
that becomes globally bound through a definition statement. 
Ihe name is then used in association with asserted tuples of 
that relation as shown here for the relation contents: 

contents ( 1 , x, y) 

In Omega-1.5, an identifier is also defined and globally 
bound as a name for a relation. The use of the identifier 
is directed, however, by the following rule: 

relation_phrase = noise_verb not? noise_verb? 

word_phrase 
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The word_phrase category was defined in the previous 
section. Clearly, it has multiple uses. The noise_verb 
category represents copulative and auxiliary verbs. One 
noise verb is required, although two are possible. 

One use of the relation_phrase category is as a verb 
phrase. This combines an auxiliary verb with a main verb. 
Examples of auxiliary verbs include is, do, has, and are. 
The main verb would be the defined identifier, as previously 
described. Valid examples of the relation_phr ase category 
might be: 

can write 
should study 
are playing 

Rules can be written in multiple tenses, depending 
upon the proper selection of verb tense and auxiliary verb. 
The present tense can be achieved by using the emphatic word 
do as the auxiliary verb: 

I do study 

The addition of the optional second noise verb in the rela- 
tion phrase definition permits the use of most combinations 
of the active, passive, and progressive active voices for 
the six basic tenses in English. Table I gives several 
examples. Tenses such as the future perfect combined with 
the progressive active voices are not permitted as they 
require three auxiliary verbs: 

I will have been calling 

Verb phrases can be easily negated. Recall that in 
Omega-1, a test for an absence of a tuple is written as: 



contents (1 ,x, y) 







TABLE I 


- 




Verb 


Tense Examples 




EXAMPLE 


VOICE 


TENSE 


I 


had called 


active 


past perfect 


I 


was calling 


progressive 

active 


past 


I 


had been called 


progressive 

active 


past perfect 


I 


will be called 


passive 


future 


I 


will have called 


active 


future perfect 



This is accomplished in Omega-1.5 by using the optional word 
not after the first auxiliary verb: 

are not playing 
do not study 
have not been called 

Applications of the relation_phrase category can 
also be written using copulative verbs. Copulative verbs 
are verbs which connect a subject with its complement. The 
complement is either a predicate noun or a predicate adjec- 
tive. The defined identifier becomes the complement when a 
copulative verb is used. Examples of a copulative verb with 
a predicate noun as its complement are: 

is the contents 
is a member 
are the components 

Examples of predicate adjectives with copulative verbs are: 

is ill 
are happy 
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felt sick 



As with verb phrases using auxiliary verbs, the verb phrases 
with copulative verbs are also easy to use in a check for an 
absence cf a tuple. The optional word not is placed after 
the copulative verb; 

is not the contents 
is not a member 
is not ill 

2 . G enera l 

In Omega-1, a relation was viewed as an object name 
combined with a tuple. Sample relations could be; 

push (user, item, stack) 
contents (list , stack) 
knew (I, proposition) 

These relations might be written in Omega-1.5 as: 

A user does push an item on a stack 
A list is the contents of the stack 
I dc know the preposition 

Figure 3.1 shows the mapping between relations in the two 
grammars. 

In Omega-1.5, the first argument to a tuple is 
placed before the relation name. This becomes the subject. 
The predicate consists of the relation phrase and the rest 
of the arguments in the tuple. These remaining arguments 
are essentially indirect and direct objects. The grammar 
specification is; 

subject r elation_phrase arguments 

where the subject is an expression and the arguments 
category calls for zero or mere expressions. If in the 
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contents (list, stack) 




A list is the contents of the stack 



Note: Noise words are -filtered during 

the translation. 





Figure 3.1 Mapping Between Relations. 

arguments there is more than one expression, a noise prepo- 
sition must be inserted between each of the expressions. 
The rationale for the preposition reguirement is discussed 
in the inplementation chapter (Chapter 4) . This restriction 
is not a great burden. If a programmer wants to write: 

give (man, dog, bene) 

in Omega-1.5, he would want to write: 

A man did give a dog a bone. 

The preposition requirement would necessitate the relation 
to be written as: 

give (man, bone , d eg) . 

and translated as: 

A man did give a bone to a dog. 
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D. LISTS 



Lists have previously been described as one of the three 
value components in the system. A sample list expression in 
Cmega-1 is: 

[red, white, blue 3 

This would be written in Omega-1.5 as: 

the_list of red, white, blue 
or the_list of red, white, and blue 

The start of a list is signaled by the term the_list. This 
again is an extensible category and will be discussed in 
chapter four. The_list maps to the open and closed brackets 
in the Omega-1 syntax (see Figure 3.2). 




.j 



Figure 3.2 Happing Between Lists. 

The comma between arguments of a list written in 
Omega-1.5 is optional. Consequently, the list 

[ man, implies, mortal ] 

could be written as: 
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the proposition nan implies mortal 

if proposition had teen defined as an extension to the 
list_starter category. The omission of commas created 
several implementation problems, and its use is therefore 
questionable. 

E. EDUCTIONS 

1 . Invocation 

There are two types of function calls in Omega-1.5. 
One type is similar to the relation format described in 
section C of this chapter. The second type differs in not 
inverting the function name with the first argument. Both 
types are described in the following definition: 

f n_application = word_phrase •(* ’function* ’)’ 

arguments 

| subject ' (’ ’predicate’ ’) ’ 
relation_phrase arguments 

The first alternative is the case without the inver- 
sion of the first argument with the function name. In the 
original design, this was the only format for a function 
call. Common Omega- 1 functions that fit this category are: 

first[ list ] 
ccns[ item , list ] 
rest[ list ] 

The Omega-1. 5 form would be: 

the first (function) of a list 

the appending (function) of an item with a list 
the rest (function) of a list 
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The notation (function) is used to signal the function call. 
It maps into the left and right brackets (see Figure 3.3). 
It can be used in a program to readily spot function calls 
without slowing down their comprehension. Specific words 
were considered to represent the left bracket in lieu cf the 
term (function), but it was felt that a specific word would 
limit the possibilities for expressing function invocations 
in a naturalized style. 




Figure 3.3 Mapping Between Functions. 

During the implementation phase, it became obvious 
that having only one format for function calls was not 
sufficient. Consider the following built-in functions in 
the McArthur interpreter: 

IsList[ item ] 

Islntf item ] 

IsStr[ item ] 

It would be extremely difficult to write these functions in 
Cmega-1.5 without inverting the argument and the function 
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name. Thus the second part of the f n_application definition 
was added. This format basically applies to any function 
that calls for a true/false or yes/no condition (the func- 
tion does not necessarily have to return a true/false or 
yes/nc) . The rule: 

If *IsStr[item] -> display {"true’} 
can now he written: 

If given an item (predicate) is a_string 
then "true" (procedure) is displayed 

where a_string maps into IsStr. 

2 • D eclaration 

Function declarations in Omega-1.5 are similar to 
function declarations in Omega-1. The only difference is 
that the word function appears in its entirety in the 
heading instead of being abbreviated as fn. The decision to 
keep the same heading was based on the mathematical nature 
usually associated with this applicative component. A func- 
tion call within a definition, however, (such as a recursive 
call) would be written in the naturalized style. An example 
of a function call in Omega- 1 and its translation in 
Cmega-1. 5 is presented below: 

Cmega-1: fn number_iterus[ list ]: if list = Nil 

-> 0 

else 1 + number_items[ rest[ list ] ]. 

Cmega-1. 5: function number_items[ list ]: 
if list = Nil then 0 

else 1 + the number_items (function) 
in the rest (function) of the list. 
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F. 



PROCEDURES 



Recall that in Cmega-1, procedure calls were almost 
syntactically identical to the assertion of a relation. The 
only distinguishing item was the use of braces in the place 
of the parentheses: 

relation: contents (5, list) 

procedure call: pushed {5 , stack} 

Procedure calls in Omega-1.5 are also identical to Cmega-1. 5 
relations with the exception of one distinguishing element. 
The synibcl (procedure) is used to identify the requirement 
to surround the arguments with braces instead of parentheses 
during translation: 

relation: 5 is the contents of the list 

procedure call: 5 (procedure) is pushed on the 

stack 

Rested procedure calls in Omega-1.5 would appear inside cut 
from a similar structure in Omega-1: 

Cmega-1: a{b{c{d}}} 

Cmega-1. 5: d (procedure) c (procedure) 

b (procedure) a 

Figure 3.4 shows the mapping between procedure calls in the 
two grammars. 

G. GENERAL 

Appendix B shows the translation of the most common 
symbols that are net translated literally from Omega- 1.5 
into Cmega-1. The word given is used to replace the cancel- 
lation symbol * in Omega-1. The rule markings, << and », 
are respectively represented as Rules and end_rules. 
Sequential control braces are replaced by begin and 
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1 




Figure 3.4 Mapping Between Procedures. 

end_block. This is similar tc the block control structures 
begin ard end in cccventional languages such as Pascal. 
Appendix C lists sample programs which illustrate syntac- 
tical structures in the Omega-1. 5 and Omega-1 grammars. 
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IV. IMPLEMENTATION and a pplications 



A. GENEEAL 

A quick translator was developed to test the design 
decisions of the Omega-1. 5 grammar. There were two goals in 
the development of the translator. The first goal was 
simply tc evaluate the feasibility of the 1.5 grammar. A 
second goal was to explore extensible options to create a 
flexible environment for the grammar. The implementation 
language was Turbo Pascal £Ref. 18]. Pascal was chosen for 
its simplicity as a high-level language. Turbo Pascal was 
selected as one of the better Pascal environments for proto- 
type programming. The built-in editor and Turbo's speed of 
compilation facilitated the testing and changing of vaiicus 
design decisions. The inefficiency in the object code and 
the lengthy run-time system that is added during compilation 
were net considered tc be serious hindrances. 

E. SCANNER AND PARSER 

The stages of the translator were arranged in a pipeline 
configuration. The scanner processes input characters to 
recognize tokens. As a token is recognized, it is fed into 
the parser. Token classes consist of identifiers, delim- 
iters, strings, and integers. Identifiers are described as: 

(letter) (((letter) ] (digit) | _) * 

((letter) | (digit)))* 

where letters can either be upper or lower case. A digit is 
simply an element of the set (0..9). 

The scanner has two filters. The first screens out 
comments, and the second filters characters that are net in 



A carriage return and line 



the 1.5 grammar (such as tabs) . 
feed is converted to a space. 

Parsing is done in one pass by recursive descent. This 
required the Omega-1.5 grammar to be massaged into IL(1) 
form ty removing left- recursion and nondeterminism. 

C. TB ANSLATION PBOCESS 

Translations are performed straight off the parse. 
Brief comments on some of the more intricate aspects of the 
translation process will be presented. Problem areas will 
be highlighted. 

Previous figures have shown a mapping from several 1. 5 
statements into the Cmega-1 syntax. These figures illus- 
trate the switching cf the first argument and the relation 
name. The relation: 

A list is the contents of the stack 

comes cut of the pipeline as: 

list ( contents, stack ) 

In this case, contents and list must be switched (see Figure 
4.1a). This was relatively easy. 

Figure 4.1b shows a more difficult situation. Here, the 
first argument is a function call. The entire function call 
must be switched with the relation name. Additional 
complexity could result with nested calls. The solution was 
to have an output buffer consisting of an array of strings. 
The function call, first[list], was converted during the 
translation into a single string. Thus, the switch only 
involved two strings. 

Another difficulty was inserting commas between argu- 
ments. A comma must be placed after each argument in a 
tuple with two exceptions. One exception is with a unary 




Figure 4.1 Switching Relation Name and First Argument. 

tuple. The second exception is after the last argument in a 
multiple-argument tuple. Commas therefore could not be 
inserted without looking ahead in the translation. 

The open parenthesis of a relation in Omega-1 does not 
have a corresponding component in Omega- 1.5. In the imple- 
mentation, the auxiliary verb without a (function) , (predi- 
cate) , or (procedure) in front was used to map into the open 
parenthesis. This was straightforward. The challenge was 
in closing the open parentheses, brackets, and braces. 
Flags had to be set to insert the proper closing after the 
last argument. This is compounded with: 

The appending (function) of the item with the 
list is the contents. 

Here, a closed bracket must be inserted before a closed 
parenthesis : 

contents (cons[ i tem, list ]) . 

Ncise words (prepositions, articles, auxiliary verbs) 
are filtered during translation, as previously discussed. 
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Extensions to the ncise words (section D) are declared 
through a definition statement. These definition statements 
must also he filtered. In the implementation, the defini- 
tion was translated into the buffer, with the buffer pointer 
being reset upon discovering that the definition was for a 
noise word. Thus the definition was deleted before the 
buffer was dumped to the output file. 

One final implementation problem involved the use of 
prepositions between arguments. Originally, this was not a 
requirement. A problem could result though with the 
following two assertions: 

A list (procedure) is pepped off a stack. 

A list (procedure) is pushed on a stack. 

This would be translated as: 

popped {list, stack) . 
pushed [list, stack) . 

If the period after the first statement was accidentally 
emitted, however, the error would be accepted with the 
following translation: 

popped {list, stack, pushed {list, stack) ) . 

Ey inserting the mandatory preposition after the second 
argument, this condition is avoided. Lists that are written 
without the comma option between arguments would still face 
this problem. 

D. EXTENSIONS 

A key element in Omega-1.5 is the ability to add noise 
words. This feature is essential if flexibility in the 
design is to be achieved. The extensions primarily apply to 
auxiliary verbs, to prepositions, and to words which signal 
the start of a list. 
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1 . Noise Verb s 

Four auxiliary verbs were built into the grammar: 
is, are, has, and do. Suppose, however, that we had the 
relation : 

if *pop (user , stack) -> ... 
and we wanted to translate it as: 

If given a user does pop a stack then ... 

We would need to define the auxiliary verb does. This is 
done by: 

"Does" (procedure) is defined as a noise_verb. 

The list of noise verbs was implemented as an array of 
strings. The array ceiling was arbitrarily set at twenty. 
The definition statement is not translated — in this case it 
simply adds the word does to the list of noise verts. When 
an auxiliary verb is expected during the parse, the trans- 
lator does a sequential search through the array. 

2 . Noise Preposi tions 

Noise prepositions were handled in the same manner 
as noise verbs. Eleven common prepositions were built into 
the translator (and the grammar) . One of the eleven 
built-in prepositions is actually a conjunction rather than 
a preposition, since programming experience showed that the 
conjunction and could add a great deal of clarity in many 
situations that called for an optional preposition. The 
following example shows a suitable case. In this instance, 
and is used to connect two indirect objects: 

Cmega-1 : donate (man, money, poor, needy) 

Cmega-1.5: A man did donate money to the poor 

and to the needy 
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